This invention relates to diagnostic systems generally and, more specifically, to expert systems-based diagnostic systems.
With the continual increase in the complexity, ubiquity and importance to users of networked electronic devices such as cable modems, personal computers, security systems and the like, the demand for diagnostic services for these devices is exploding. The costs of these services tend to be high, since the systems to be serviced are often widely dispersed. The high costs of diagnosing equipment problems is exacerbated when interaction with the end user is desirable or unavoidable, since the costs of maintaining a sufficient inventory of skilled technicians to service all customer inquiries in a timely fashion is high, as is the cost of the systems required to support said technicians.
It has become common in the art for expert systems to be used by skilled technicians to assist in quickly diagnosing equipment problems. Such systems are well-known in the art, and generally proceed by what is known as case-based reasoning using inference engines. Basically, a series of facts is provided to the inference engine, which then applies rules to these facts. These rules may then prompt the service technician to perform specific tests or measurements, the results of which become in turn new facts to feed into the inference engine. The body of rules and facts used by the inference engine is known as the knowledge base. In general, highly specialized knowledge bases are built up in the art to capture as much of the knowledge of a particular problem domain, such as troubleshooting cable modems or home security systems, as possible. While it is most common for expert systems to be used by experts, there is a trend in the art to make these systems available to the end users by placing an easy-to-use interface such as a web page or an interactive troubleshooting menu between the end user and the expert system.
Another trend in the art is to make available, to trained technicians, testing interfaces. Such interfaces allow the trained technician to perform tests on electronic devices such as cable modems without regard for their physical location, by sending commands over a data network such as the Internet and receiving the results over the same network, in both cases via these test interfaces. For example, in the cable modem industry, technicians located at a cable provider's head-end office, which is the provider facility located at the nearest point to the cable subscriber, can send test commands to the cable modem over the cable. Similarly, technicians can attempt to “ping” the cable modem over the Internet to check if it is properly connected to the Internet and properly configured as a member of the network (pinging is a technique well known in the art, in which a simple data packet is passed to the target machine and returned from it back to the originator; it checks that the machines are connected via the network and it measures the round trip time to send and receive the packets). These tools are available for many types of electronic equipment; another example is the ability of home security system service providers to query the state of detectors at a home from their monitoring facilities. Of course, the types of monitoring and testing facilities described here are not typically available to the end users of the electronic systems. The end user must contact the service provider when a problem occurs, and a trained technician must perform any diagnostics.
To make clear the shortcomings of the current situation, refer to FIG. 1. Consider the scenario of an end user 101 of a cable modem Internet service who is unable to connect to the Internet 106 from his home computer. The user makes a phone call over the public switched telephone network 102 to the cable company to get assistance. A support technician 100 is connected to the end user, and requests the customer's home phone number. The technician queries a Customer Relationship Management (CRM) application 110 using the end user's phone number to obtain customer information, which is stored in a relational database 115. The technician confirms the end user's identity and then asks the customer to hold for a moment. Using a network management software system 130 the technician looks up the customer's Internet Protocol (IP) address and the machine ID of the cable modem 105. Armed with this complete information about the end user the technician opens a new case in his diagnostic software system 120 (which in some embodiments is included as a submodule of the CRM software system 110). The diagnostic software, in a process well known in the art, asserts the information about the new case to the inference engine 121, which adds the facts thus asserted to the modem knowledge base 125. The knowledge base contains a large set of facts and rules pertaining to cable modem diagnostics, in essence comprising a large subset of the knowledge possessed by skilled technicians in a structured, machine-usable form. When facts are added to the knowledge base, the inference engine looks for rules in the knowledge base which match the new facts, possibly in conjunction with existing facts. If rules are found (for instance, a rule for the “new case entered” fact), the inference engine activates those rules. Activation of a rule means that whatever is specified as the output of the rule is asserted. The output is typically one or more new facts, which in turn can trigger new rules. The inference engine proceeds until it has exhausted all facts and rules that are triggered by the initial fact assertion.
During this process, the inference engine may print out prompts to the technician, such as “ping the modem”. The technician would do this by sending a standard ping request over the Internet 106 to the cable modem, a technique well established in the art. The technician, after pinging the cable modem, would assert the result of the ping test as a new fact in the inference engine. This fact may in turn trigger other rules. Other common actions which would be prompted by the inference engine in this scenario would include using software interfaces available in the art to the cable company head-end office 140 to send commands to, and receive status information from, the cable modem via the direct test connection 150 (that is, directly from the cable head-end to the cable modem, without using the Internet or its protocols). Such tests can determine certain fault conditions in the cable modem hardware or software, and can reinitialize the cable modem software. It will also be common for the inference engine to prompt the technician to ask the end user questions such as “tell me what lights you see on your cable modem”, or “please check to ensure the cable is tightly connected to the cable modem, and let me know what you found when you are done”.
Using these various sources of data, the inference engine provides the technician with assistance by providing an ordered series of steps to attempt to determine and correct the problem with the cable modem. This scenario is typical of the diagnostic systems in common use for addressing problems with electronic devices. Systems used for other types of devices, such as home or commercial building security systems, personal computers, game playing systems with Internet connections, and many other Internet- or telephony-enabled devices (i.e., devices with a connection to any network that makes diagnostics possible), will differ in their details based on the unique systems appropriate to the device and network characteristics (for example, security systems do not have head-end offices but rather monitoring centers). However, the general approach outlined in this scenario is typical of those in use in the art.
One disadvantage inherent in the art as described in the above scenario is that the components used in the prior art scenario do not operate as a system, but rather as a set of tools that are available to the trained technician. Some systems in the art combine an expert system with diagnostic tools analogous to the ping and modem test tools in the scenario just presented. Other systems have provided a limited degree of self-service capability to the end users by providing the end user with web-based frequently asked questions (FAQ's) guides, or simple case-based reasoning (e.g., “Try this . . . did it work? . . . no? . . . then try this . . . ”). In all the systems extant in the art, however, there are essential components which remain outside the system, and the systems rely heavily on the trained technicians to solve problems completely. Since trained technicians are expensive to recruit, train, and retain, it is clearly desirable to deploy systems in which the expert system, the end user, and the diagnostic tools interwork seamlessly without the need for technician intervention for most problems (expert systems known in the art generally would be able to solve a large fraction of reported problems if all information were readily at hand). The present invention is addressed, among other things, to this need for interactive diagnostic systems driven by expert systems. In particular, a method and system for troubleshooting of networked electronic devices, driven by an inference engine which controls both the user interaction and the operation of and collection of data from diagnostic tools, are disclosed.
The term event as used in this specification and the claims attached hereto is used to refer both to the notification that an event has occurred (such as a call arriving at a switch, or a database query being completed), as well as to the passing of the data associated with that event (in the two examples, this would be the number at which the call is arriving and potentially the number from which the call came, and the results of the database query, respectively); it is common in the art for events to be passed as data packets which indicate the event that occurred, where it occurred and when, and which provides associated data as part of the event packet. This should be understood to be the meaning of the word event herein unless specifically stated otherwise for a particular instance of the word.
In the appended figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.